Процесс разработки программного обеспечения должен содержать этапы инициации (организации) проекта, оценки проекта, анализа и проектирования, конструирования и внедрения системы. Этап инициации проекта, с точки зрения разработчика, должен включать подготовку заказчиком требований к новой системе, описание ее функций и структуры, оправдание ее с точки зрения бизнеса и получение одобрения со стороны руководства для того, чтобы приступить к следующим этапам разработки. Если заказчиком выступает подразделение организации, необходимо одобрение руководителя подразделения, если заказчик - организация в целом, то руководителей организации. Первоначальные требования к системе направляются, как правило, в ИТ-подразделение, которое оценивает факторы, критичные для успеха проекта и его качества. Необходимо выяснить, насколько проект согласуется с общей стратегией банка в области развития бизнеса и использования информационных технологий, приблизительно оценить общие затраты на проект, а также каким образом и кем должен осуществляться контроль над проектом. Оценка проекта и его согласование были рассмотрены выше, поэтому мы здесь лишь упомянем о них. В направлении дальнейшей детализации необходимо выбрать несколько вариантов реализации программного обеспечения и точно оценить стоимость каждого варианта, трудности, связанные с его осуществлением, время на осуществление, программные средства и инструменты, необходимые для проекта, исполнителей проекта, а также преимущества каждого варианта. Кроме того, требуется описать недостатки существующей системы и как они будут устранены при внедрении нового программного обеспечения. В итоговую оценку необходимо включить меры по изменению бизнес-процессов и структуры организации, которые сопровождают внедрение системы. Детальную оценку проекта осуществляет ИТ (проектная команда), заказчик выбирает окончательный вариант решения. Итоговый документ должен быть подписан заказчиком и проектным руководством, руководителем ИТ. Этап анализа и прогнозирования включает в себя разработку проектной документации, в деталях описывающей работу будущей системы, ее структуру, технические и программные средства, необходимые для ее функционирования. Этот этап важен для облегчения дальнейшей работы над системой. Итогом данного этапа должны явиться одна или несколько спецификаций системы, которые готовятся разработчиком при поддержке заказчика. Мы уже отмечали, что для наших целей не будем различать различные типы спецификаций. Отметим лишь, что вне зависимости от их названия они должны содержать: * описание бизнеса (бизнес-процессы и функции, которые будут автоматизированы): - детальное описание существующих бизнес-процессов и каким образом они будут затронуты при внедрении системы; - детальное описание новых бизнес-процессов, которые будут созданы или получены при изменении существующих; - описание мер контроля, которые будут внедрены в новой системе; описание программно-аппаратного обеспечения, необходимого для функционирования системы: - операционная система(ы), которая будет использоваться; - сетевая среда, оборудование и протоколы; - средства разработки новой системы; - средства защиты информации; - как новые платформы будут включены в существующую информационную инфраструктуру; * спецификация функциональности системы: - общее описание функциональности системы как в повествовательной форме, так и в виде диаграмм; - разбиение системы на модули; - соответствие модулей бизнес-требованиям к системе. Должно быть описано, каким требованиям отвечает каждый модуль. Все бизнес-требования должны покрываться модулями системы; - модель данных, используемая в системе (диаграмма "сущность- связь" или аналогичные). Функциональность, вынесенная в серверную часть системы; - описание того, каким образом будут реализованы требования к информационной безопасности, производительности и надежности системы; - детальное описание интерфейсов с другими системами; - список разрабатываемых программ (включая вспомогательные) и параметры для их запуска; - список ошибок и предупреждений, генерируемых системой; - спецификация должна быть четко структурированной и содержать оглавление, алфавитные указатели, глоссарий и список используемых терминов. Все спецификационные документы подписывает разработчик и предоставляет для ознакомления заказчику. Написание подробных спецификаций (постановку задачи) можно заменить использованием методики создания прототипов. При этом прогрессивном методе используется итерационный подход. Описание будущей системы производится через согласование интерфейсов пользователя с системой. С будущими пользователями системы обсуждаются и утверждаются экранные формы, соответствующие различным функциям системы. Вместе с внешним видом этих форм описываются соответствующие им входные и выходные данные. Другими словами, время на подготовку документов практически не тратится, пользователь рассказывает, что ему нужно, разработчик создает модель и презентует ее пользователю, который высказывает свои замечания и т.д., пока решение (или по крайней мере его внешний вид) не согласовывается. Выгодой этого подхода являются меньшие сроки разработки системы, следовательно, меньшие затраты на разработку. Решение об использовании методики создания прототипов принимается до начала этапа анализа и проектирования, на этапе выбора варианта реализации системы. При принятии решения должны быть оценены следующие риски: * рамки проекта могут быть значительно расширены без формального одобрения, так как пользователи системы могут добавлять "полезные" с их точки зрения функции; * прототипы описывают только интерфейсы пользователей, и такие вопросы, как информационная безопасность, могут быть упущены на этапе проектирования; * не для всех компонент системы можно создать прототипы; * использование прототипов не так детально описывает разрабатываемую систему, как написание спецификаций. Следствием могут явиться трудности с поддержкой и сопровождением в долгосрочной перспективе, а также недостаточный уровень тестирования каждого модуля. На этапе конструирования формально описанные требования к системе, созданные на стадии анализа и проектирования, преобразуются в рабочую систему. Разработка включает в себя создание структуры программы, кодирование, создание структуры базы данных и тестирование на уровне модулей системы, системы в целом и интерфейсов с внешними приложениями. Система должна согласовываться с формальными требованиями к ней. В случае внесения существенных изменений в систему, не описанных в проектной документации, эти изменения должны быть согласованы с заказчиком и внесены в спецификации. Программное обеспечение разрабатывается с использованием структурного подхода, при этом должны соблюдаться ранее установленные стандарты кодирования. Исходные коды содержат комментарии в количестве, необходимом для понимания структуры исходного кода и ее функциональности. Следует максимально снизить риски, возникающие при смене разработчиков. Программный код должен быть составлен на основе уже упоминавшихся стандартов. Разработчик при этом использует систему контроля версий исходных кодов. При внесении изменений в исходный код описывается, какие изменения и с какой целью вносились.

Заказать аналогичную работу

Каталог докладов, эссе

Узнайте цену написания своей работы

Похожие работы:

• Стадии разработки
Процесс разработки программного обеспечения должен содержать этапы инициации (организации) проекта, оценки проекта, анализа и проектирования, конструирования и внедрения системы. Этап инициации проек...


• Оценка эффективности разработки
Масштаб и степень следования стандартам разработки программного обеспечения могут зависеть от размера и характера проекта, а также от того, какие инструменты разработки используются. Для небольших, не...


• Теоретические разработки экономистов России
Развитие экономических воззрений в России проходило в тесной связи с общим движением науки в других странах. Труды и разработки российских ученых во многом оригинальны; многие положения, обоснования, ...


• Порядок разработки бизнес-плана
Если законченный вариант бизнес-плана должен начинаться с резюме, то процесс его разработки обычно резюме завершается. Главное здесь – правильное формулирование целей бизнес-плана, количественных и ка...


• Условия разработки кадровой политики
На кадровую политику в целом, содержание и специфику конкретных программ и кадровых мероприятий влияют факторы двух типов: внешние по отношению к организации и внутренние. Факторы внешней среды Фак...